Software development is typically performed as group projects. A subject software system is developed through design efforts, test efforts, implementation efforts and maintenance efforts. There may be different groups and different group members participating in each of these efforts. Throughout these efforts and among the work group members, various modeling and other development tools are used for increased communication and consistency in developing the subject software system. A software traceability management system is one such tool.
When a software development artifact is modified, the developer would like to know what other artifacts need to be modified in order for the subject system to remain consistent. An “artifact” is the persistent result of work done by a user, typically persisted in a file system such as a model and source code. Being able to perform impact analysis before changing an artifact has been a longstanding (but elusive) need in software development for years. One of the main issues is managing change to software/system requirements. Without the ability to perform impact analysis, artifacts produced as part of the development process drift apart and become inconsistent. This leads to misunderstandings, wasted time, schedule slips and non-conformance to requirements. In short, failure to manage change leads to higher development costs.
For example, when two software artifacts are connected by a dependency traceability relationship, a change to the first artifact might require a change to the second artifact in order to maintain the semantics of that relationship. These dependence traceability relationships are an essential mechanism for determining impact analysis, i.e., determining what other artifacts need to be updated following a change to a given set of artifacts.
Traditional solutions attempt to solve the problem using manually created and maintained traceability links. Links are manual because the variety of artifact types spans domains: for example, requirements are human readable while code is written in a formal technical language. Complex software systems have hundreds, if not thousands of requirements, and there are many to many relationships between artifact types: requirements, needs, designs, tests, code, etc.
Past attempts to create and maintain the traceability relationships fail because the cost to the development team outweighs the benefit. Maintaining traceability links is an arduous task even for a relatively small development effort and this is one of the main reasons existing traceability solutions fail. There are many accounts that document this issue and the difficulty in solving it.